feat: add support for OpenAI SDK v5 #644
Conversation
|
|
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to 3e0b7b1 in 55 seconds. Click for details.
- Reviewed
52lines of code in2files - Skipped
0files when reviewing. - Skipped posting
5draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. packages/instrumentation-openai/src/instrumentation.ts:28
- Draft comment:
Import updated to include OpenAIVersion for type safety. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, stating that an import was updated for type safety. It does not provide any actionable feedback or suggestions for improvement. According to the rules, purely informative comments should be removed.
2. packages/instrumentation-openai/src/instrumentation.ts:121
- Draft comment:
Updated version range to [">=3.1.0 <6"] to support OpenAI SDK v5. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, as it only states what was done without providing any actionable feedback or suggestions. It doesn't ask for confirmation or suggest any changes.
3. packages/instrumentation-openai/src/instrumentation.ts:213
- Draft comment:
Changed patchOpenAI parameter type to OpenAIVersion for clarity and support for v5. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, explaining a change that was made. It does not provide a suggestion, ask for confirmation, or point out a potential issue. It violates the rule against making purely informative comments.
4. packages/instrumentation-openai/src/instrumentation.ts:602
- Draft comment:
Updated _wrapPromise version parameter to use OpenAIVersion, ensuring v5 is handled like v4. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, describing a change made in the code without providing any actionable feedback or suggestions. It does not ask for confirmation or suggest improvements, nor does it point out any potential issues with the change.
5. packages/instrumentation-openai/src/types.ts:3
- Draft comment:
Extended OpenAIVersion union to include "v5", ensuring proper type support. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, stating what was done without providing any actionable feedback or suggestions. It doesn't ask for confirmation or suggest any improvements.
Workflow ID: wflow_bm8yv8lJH3cH4kRw
You can customize 
WalkthroughExpands OpenAI SDK compatibility from ">=3.1.0 <5" to ">=3.1.0 <6", exports Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant Instrumentation as instrumentation.ts
participant Wrapper as _wrapPromise
Caller->>Instrumentation: call patchOpenAI(type, version: OpenAIVersion)
Instrumentation->>Wrapper: _wrapPromise(type, version, span, promise)
alt version === "v3"
Wrapper->>Wrapper: apply v3-specific handling
else v4 or v5
Wrapper->>Wrapper: apply non-v3 (shared) handling
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Assessment against linked issues
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
|
@nirga I did sign it but it still haven't refreshed the status. As for bumping the version, you mean the dev dependency or manually bump the package.json version? |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/instrumentation-openai/src/instrumentation.ts (1)
216-216: Clarify defaulting behavior: v5 currently shares the v4 code pathTo avoid confusion for future readers, annotate that v5 intentionally uses the non-v3 branch.
Apply this minimal inline comment:
- version: OpenAIVersion = "v4", + version: OpenAIVersion = "v4", // v5 currently shares v4 behavior
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/instrumentation-openai/src/instrumentation.ts(4 hunks)packages/instrumentation-openai/src/types.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
packages/instrumentation-openai/src/instrumentation.ts (1)
packages/instrumentation-openai/src/types.ts (1)
OpenAIVersion(3-3)
🔇 Additional comments (3)
packages/instrumentation-openai/src/types.ts (1)
3-3: OpenAIVersion union extended to include v5 — looks goodThis aligns the public type surface with the widened SDK support.
packages/instrumentation-openai/src/instrumentation.ts (2)
28-28: Type import update is consistent with the new OpenAIVersionImporting the union from a single source keeps version handling consistent.
605-605: Confirmed: APIPromise._thenUnwrap remains stable in v5, returning the unwrapped entity
We’ve verified that in OpenAI Node SDK v5 (5.0.0-alpha) the private-style helper_thenUnwrapstill exists and continues to resolve to the parsed data payload (not anOpenAIResponsewrapper), matching v4 behavior.• Note that
_thenUnwrapis not part of the public API and may change without notice.
• For guaranteed stability, you can useawait(which yields the parsed entity), or the new public methodsasResponse()(to get the rawResponse) andwithResponse()(to get both{ data, response }).
| @@ -119,7 +119,7 @@ export class OpenAIInstrumentation extends InstrumentationBase { | |||
| protected init(): InstrumentationModuleDefinition { | |||
| const module = new InstrumentationNodeModuleDefinition( | |||
| "openai", | |||
| [">=3.1.0 <5"], | |||
| [">=3.1.0 <6"], | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Widened module semver range to >=3.1.0 <6 — verify repo-wide alignment (docs, deps, tests)
Ensure we don’t have stale references to "<5" elsewhere and that CI/tests cover v5.
Run the following to find and update any lingering constraints and to surface any openai dependency ranges:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Searching for legacy range '>=3.1.0 <5' across the repo..."
rg -n ">=3\.1\.0\s*<5" || true
echo
echo "Searching for 'openai' version constraints in package.json files..."
fd -a package.json | while read -r f; do
hits=$(rg -n '"openai"\s*:\s*"[^\"]+"' "$f" || true)
if [[ -n "$hits" ]]; then
echo "$f"
echo "$hits"
echo
fi
done
echo "Checking docs/workflows for hardcoded SDK support statements..."
rg -n "(OpenAI SDK|openai@|>=3\.1\.0\s*<5|<5)" --glob '*.md' --glob '.github/**/*.yml' || trueLength of output: 5204
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Inspecting instrumentation-openai package.json for openai dependency entries..."
grep -R '"openai"' -n packages/instrumentation-openai/package.json || trueLength of output: 300
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Displaying lines 40-80 from packages/instrumentation-openai/package.json to inspect dependency sections..."
sed -n '40,80p' packages/instrumentation-openai/package.jsonLength of output: 1173
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Listing all GitHub workflow files:"
fd -a -e yml .github/workflows
echo
echo "Scanning workflows for 'openai' references:"
rg -n "openai" .github/workflows
echo
echo "Scanning workflows for matrix definitions:"
rg -n "matrix" .github/workflowsLength of output: 505
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Inspecting peerDependencies in instrumentation-openai package.json..."
grep -R '"peerDependencies"' -n packages/instrumentation-openai/package.json || true
sed -n '1,39p' packages/instrumentation-openai/package.json
echo
echo "Checking for GitHub workflow files..."
if [ -d ".github/workflows" ]; then
find .github/workflows -type f -name '*.yml'
else
echo ".github/workflows directory not found"
fi
echo
echo "Scanning workflows for 'matrix' or 'openai' references..."
grep -R -n -E 'matrix|openai' .github/workflows || trueLength of output: 1578
Ensure OpenAI v5 is covered in tests, deps, and CI
- ✅ No legacy
>=3.1.0 <5ranges found in code or docs. - packages/instrumentation-openai/package.json
- devDependencies still pin
"openai": "4.38.3"(tests only exercise v4). - No
peerDependenciesentry foropenai—add:"peerDependencies": { "openai": ">=3.1.0 <6" }
- devDependencies still pin
- CI workflows (
.github/workflows/ci.yml) have no matrix for multipleopenaiversions.- Introduce a job matrix to test against at least
[email protected]and[email protected].
- Introduce a job matrix to test against at least
- After adding peerDeps and CI matrix, update devDependency or use
npm install openai@${{ matrix.version }}in the test job.
🤖 Prompt for AI Agents
In packages/instrumentation-openai/src/instrumentation.ts around line 122, tests
and package metadata don’t cover OpenAI v5: add a peerDependencies entry in
packages/instrumentation-openai/package.json with "openai": ">=3.1.0 <6"; stop
pinning openai in devDependencies (or update it to a range that includes v5) so
local dev isn’t the only source of truth; modify .github/workflows/ci.yml to add
a job matrix for openai versions (at minimum 4.x and 5.x) and in the test job
run npm install openai@${{ matrix.version }} (or use npm ci after adjusting
package.json) so CI actually runs tests against both versions; ensure tests pass
with v5 and adjust any version-specific mocks or imports accordingly.
|
@hmnzr the dev dependency in the package.json |
|
@nirga done! |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (1)
packages/instrumentation-openai/package.json(1 hunks)
| @@ -55,7 +55,7 @@ | |||
| "@types/mocha": "^10.0.10", | |||
| "@types/node": "^24.0.15", | |||
| "mocha": "^11.7.1", | |||
| "openai": "4.38.3", | |||
| "openai": "5.12.2", | |||
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Use a caret range for devDependency and verify Node.js >= 18 in CI/tooling
Pinning openai to an exact version is inconsistent with the rest of devDependencies and prevents receiving compatible patch/minor updates within v5. Also, the OpenAI SDK v5 requires Node.js >= 18. Make sure your CI/tooling uses Node >= 18, otherwise installs/tests may fail even if this package’s engines allow >=14.
Apply this diff to align the semver policy:
- "openai": "5.12.2",
+ "openai": "^5.12.2",If you want to make the Node requirement explicit in this package to avoid confusion for contributors running tests locally, consider bumping the engines field (outside this hunk). Example:
{
"engines": {
"node": ">=18"
}
}Run this script to verify Node versions configured across the repo:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Searching engines declarations across package.json files..."
rg -n '"engines"\s*:\s*{' -A 3 package.json packages/**/package.json || true
echo
echo "Inspecting GitHub Actions node setup (if any)..."
if [ -d .github/workflows ]; then
rg -n "setup-node" -A 8 .github/workflows || true
rg -n "node-version" -A 2 .github/workflows || true
else
echo "No .github/workflows directory found."
fi
echo
echo "Checking local Node version config files..."
for f in .nvmrc .tool-versions .node-version; do
if [ -f "$f" ]; then
echo "== $f =="
cat "$f"
echo
fi
doneLength of output: 3790
Align openai to semver policy & confirm Node.js ≥18
- In packages/instrumentation-openai/package.json, change the pinned
openaidevDependency to a caret range so that patch/minor updates within v5 are picked up. - CI already sources Node.js version from
.nvmrc(currently “20”), so the OpenAI SDK v5 requirement (Node ≥18) is satisfied. - (Optional) To make the Node.js requirement explicit for local development, you can add an
enginesfield to this package’s package.json:
--- a/packages/instrumentation-openai/package.json
+++ b/packages/instrumentation-openai/package.json
@@ devDependencies
- "openai": "5.12.2",
+ "openai": "^5.12.2",Optional engines snippet:
{
"engines": {
"node": ">=18"
}
}🤖 Prompt for AI Agents
In packages/instrumentation-openai/package.json around line 58, the
devDependency "openai" is pinned to an exact version ("5.12.2"); change it to a
caret range (e.g., "^5.12.2") so minor/patch updates within v5 are picked up,
and optionally add an "engines" field with "node": ">=18" to make the Node.js
requirement explicit for local development.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
|
Like I suspected @hmnzr - it requires some updates to the instrumentation code |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
packages/instrumentation-openai/src/instrumentation.ts (1)
118-126: Widened semver to >=3.1.0 <6 — LGTM; ensure metadata/CI also reflect v5 coverageChange looks good here. Please make sure package metadata (peerDependencies) and CI test matrix also include
openaiv5 so we actually exercise these paths in CI. This was already raised earlier; echoing for alignment.
🧹 Nitpick comments (2)
packages/instrumentation-openai/src/instrumentation.ts (2)
28-28: Use type-only import to avoid runtime side-effectsThese are types only; importing with
import typeprevents emitting a runtime import and is safer with TS configs like verbatimModuleSyntax.Apply this diff:
-import { OpenAIVersion, OpenAIInstrumentationConfig } from "./types"; +import type { OpenAIVersion, OpenAIInstrumentationConfig } from "./types";
367-380: Guard against malformed tool entriesWhile the SDK should provide
functionwhentype === "function", a defensive check avoids runtime errors if inputs are malformed or come from mocks.Apply this diff:
- params.tools?.forEach((tool, index) => { - if (tool.type !== "function") { - return; - } + params.tools?.forEach((tool, index) => { + if (tool.type !== "function" || !tool.function) { + return; + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these settings in your CodeRabbit configuration.
📒 Files selected for processing (1)
packages/instrumentation-openai/src/instrumentation.ts(9 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
packages/instrumentation-openai/src/instrumentation.ts (3)
packages/instrumentation-openai/src/types.ts (1)
OpenAIVersion(3-3)packages/traceloop-sdk/src/lib/tracing/decorators.ts (1)
tool(276-282)packages/ai-semantic-conventions/src/SemanticAttributes.ts (1)
SpanAttributes(17-59)
🔇 Additional comments (4)
packages/instrumentation-openai/src/instrumentation.ts (4)
213-216: Signature updated to use OpenAIVersion with sensible default — LGTMThe expanded version typing keeps the branching logic intact and future-proofs the signature.
403-421: Streaming APIPromise typing switch — LGTMUsing
openai.APIPromise<Stream<...>>aligns with v4/v5 typing for streaming responses.
435-436: Initialize refusal field — LGTMPre-populating
refusal: nullmatches v4/v5 object shape and avoids optional chaining later.
707-716: Span attributes for tool_calls gated by type — LGTMOnly emitting tool call attributes when
type === "function"avoids mislabeling other tool types.
| const currentToolCall = | ||
| result.choices[0].message.tool_calls[toolCall.index]; | ||
|
|
||
| if (toolCall.id) { | ||
| result.choices[0].message.tool_calls[toolCall.index].id += | ||
| toolCall.id; | ||
| currentToolCall.id += toolCall.id; | ||
| } | ||
| if (toolCall.type) { | ||
| result.choices[0].message.tool_calls[toolCall.index].type += | ||
| toolCall.type; | ||
| } | ||
| if (toolCall.function?.name) { | ||
| result.choices[0].message.tool_calls[ | ||
| toolCall.index | ||
| ].function.name += toolCall.function.name; | ||
| currentToolCall.type += toolCall.type; | ||
| } | ||
| if (toolCall.function?.arguments) { | ||
| result.choices[0].message.tool_calls[ | ||
| toolCall.index | ||
| ].function.arguments += toolCall.function.arguments; | ||
|
|
||
| if (currentToolCall.type === "function") { | ||
| if (toolCall.function?.name) { | ||
| currentToolCall.function.name += toolCall.function.name; | ||
| } | ||
| if (toolCall.function?.arguments) { | ||
| currentToolCall.function.arguments += | ||
| toolCall.function.arguments; | ||
| } | ||
| } |
There was a problem hiding this comment.
Bug: concatenating tool_call.id/type corrupts values; assign instead of appending
Using += for id and type will produce incorrect values (e.g., "functionfunction") and can break the subsequent currentToolCall.type === "function" check. IDs and types are not streamed token-by-token; assign them.
Apply this diff:
- const currentToolCall =
- result.choices[0].message.tool_calls[toolCall.index];
+ const currentToolCall =
+ result.choices[0].message.tool_calls[toolCall.index];
if (toolCall.id) {
- currentToolCall.id += toolCall.id;
+ currentToolCall.id = toolCall.id;
}
if (toolCall.type) {
- currentToolCall.type += toolCall.type;
+ currentToolCall.type = toolCall.type;
}
if (currentToolCall.type === "function") {
if (toolCall.function?.name) {
currentToolCall.function.name += toolCall.function.name;
}
if (toolCall.function?.arguments) {
currentToolCall.function.arguments +=
toolCall.function.arguments;
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const currentToolCall = | |
| result.choices[0].message.tool_calls[toolCall.index]; | |
| if (toolCall.id) { | |
| result.choices[0].message.tool_calls[toolCall.index].id += | |
| toolCall.id; | |
| currentToolCall.id += toolCall.id; | |
| } | |
| if (toolCall.type) { | |
| result.choices[0].message.tool_calls[toolCall.index].type += | |
| toolCall.type; | |
| } | |
| if (toolCall.function?.name) { | |
| result.choices[0].message.tool_calls[ | |
| toolCall.index | |
| ].function.name += toolCall.function.name; | |
| currentToolCall.type += toolCall.type; | |
| } | |
| if (toolCall.function?.arguments) { | |
| result.choices[0].message.tool_calls[ | |
| toolCall.index | |
| ].function.arguments += toolCall.function.arguments; | |
| if (currentToolCall.type === "function") { | |
| if (toolCall.function?.name) { | |
| currentToolCall.function.name += toolCall.function.name; | |
| } | |
| if (toolCall.function?.arguments) { | |
| currentToolCall.function.arguments += | |
| toolCall.function.arguments; | |
| } | |
| } | |
| const currentToolCall = | |
| result.choices[0].message.tool_calls[toolCall.index]; | |
| if (toolCall.id) { | |
| currentToolCall.id = toolCall.id; | |
| } | |
| if (toolCall.type) { | |
| currentToolCall.type = toolCall.type; | |
| } | |
| if (currentToolCall.type === "function") { | |
| if (toolCall.function?.name) { | |
| currentToolCall.function.name += toolCall.function.name; | |
| } | |
| if (toolCall.function?.arguments) { | |
| currentToolCall.function.arguments += | |
| toolCall.function.arguments; | |
| } | |
| } |
🤖 Prompt for AI Agents
In packages/instrumentation-openai/src/instrumentation.ts around lines 484 to
502, the code currently uses string concatenation (+=) when setting tool_call
fields which corrupts values (e.g., "functionfunction"); change the assignments
so you set values directly instead of appending: assign toolCall.id and
toolCall.type to currentToolCall.id and currentToolCall.type (use =), and
likewise assign function.name and function.arguments directly when
currentToolCall.type === "function", ensuring no concatenation occurs.
| private _wrapPromise<T>( | ||
| type: "chat" | "completion", | ||
| version: "v3" | "v4", | ||
| version: OpenAIVersion, | ||
| span: Span, | ||
| promise: APIPromise<T>, | ||
| ): APIPromise<T> { | ||
| promise: openai.APIPromise<T>, | ||
| ): openai.APIPromise<T> { | ||
| return promise._thenUnwrap((result) => { | ||
| if (version === "v3") { |
There was a problem hiding this comment.
Don’t rely on private _thenUnwrap; add fallback to .then for v3 compatibility and forward-compat
_thenUnwrap is an underscored, non-public helper on APIPromise (subject to change). For v3, the returned promise won’t have it at all. This can break instrumentation for v3 (and future v5 changes). Use .then when _thenUnwrap is unavailable.
Apply this diff:
- ): openai.APIPromise<T> {
- return promise._thenUnwrap((result) => {
+ ): openai.APIPromise<T> {
+ // Prefer the public .then; fall back to _thenUnwrap only if present (v4/v5 APIPromise).
+ const apiPromise: any = promise as any;
+ const chain =
+ typeof apiPromise._thenUnwrap === "function"
+ ? apiPromise._thenUnwrap.bind(apiPromise)
+ : apiPromise.then.bind(apiPromise);
+ return chain((result: any) => {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| private _wrapPromise<T>( | |
| type: "chat" | "completion", | |
| version: "v3" | "v4", | |
| version: OpenAIVersion, | |
| span: Span, | |
| promise: APIPromise<T>, | |
| ): APIPromise<T> { | |
| promise: openai.APIPromise<T>, | |
| ): openai.APIPromise<T> { | |
| return promise._thenUnwrap((result) => { | |
| if (version === "v3") { | |
| private _wrapPromise<T>( | |
| type: "chat" | "completion", | |
| version: OpenAIVersion, | |
| span: Span, | |
| promise: openai.APIPromise<T>, | |
| ): openai.APIPromise<T> { | |
| // Prefer the public .then; fall back to _thenUnwrap only if present (v4/v5 APIPromise). | |
| const apiPromise: any = promise as any; | |
| const chain = | |
| typeof apiPromise._thenUnwrap === "function" | |
| ? apiPromise._thenUnwrap.bind(apiPromise) | |
| : apiPromise.then.bind(apiPromise); | |
| return chain((result: any) => { | |
| if (version === "v3") { |
🤖 Prompt for AI Agents
In packages/instrumentation-openai/src/instrumentation.ts around lines 604 to
611, the code calls the non-public promise helper _thenUnwrap which may not
exist on v3 APIPromise; change the wrapper to first check for
promise._thenUnwrap and use it if present, otherwise fall back to promise.then,
ensuring the same callback handling and returned APIPromise shape so
instrumentation works with v3 and future versions.
|
Yes 🙈 |
Closes #642
After bumping the SDK to v5, we've stopped receiving traces.
However, the new SDK seems to be backward compatible for chat completions and completions. I have tested a local build with
[email protected]and it's still working fine.Important
Add support for OpenAI SDK v5 in
instrumentation.tsandtypes.ts, ensuring backward compatibility.InstrumentationNodeModuleDefinitionininstrumentation.tsto support OpenAI SDK versions ">=3.1.0 <6".OpenAIVersiontype intypes.tsto include "v5".patchOpenAI()and_wrapPromise()ininstrumentation.tsto useOpenAIVersiontype for version handling.This description was created by
for 3e0b7b1. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit